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REMARKS 

The applicants have carefully considered the official action mailed on August 21, 
2007, and the references cited therein. In the official action, claims 1, 3-9, 11-18, 20-25, 
and 27-30 were rejected under 35 U.S.C. § 102(e) as anticipated by Krishnaswamy et al. 
(U.S. Patent No. 7,051,367), and claims 2, 10, 19, and 26 were rejected under 35 U.S.C. 
§ 103(a) as unpatentable over Krishnaswamy et al. in view of Lipe et al. (U.S. Patent No. 
5,748,980). By way of this response, claims 2, 4, 6, 19, 22, 26, and 29 are amended, 
claims 3, 9-16, 18, and 25 are cancelled, and claims 31-35 are added for consideration, 
thereby leaving claims 1, 2, 4-8, 17, 19-24, and 26-35 pending in this application, of 
which claims 1, 17, 24 and 31 are independent. No new matter has been added, and 
favorable reconsideration is respectfully requested in view of the foregoing amendments 
and the following remarks. 

The applicants respectfully submit that independent claim 1 is allowable over the 
art of record. Independent claim 1 is directed to a method to provide a platform-level 
network security framework that, inter alia, identifies one or more platform-level 
network security protocols associated with an extensible firmware interface (EFI). None 
of the cited references describes or suggests identifying one or more platform-level 
network security protocols associated with an EFI, as recited in claim 1 . 

The examiner appears to contend that the packet service routines (PSR's) 
described by Krishnaswamy et al. are to be construed as one or more platform-level 
network security protocols, as recited in claim 1 . While Krishnaswamy et al. describe 
that the PSR's may service a protocol type, such as an Internet protocol (IP), TCP/IP, or 
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an Address Resolution Protocol (ARP), Krishnaswamy et al. fail to describe or suggest 
any security protocols, much less platform-level network security protocols. 
[Krishnaswamy et al, 4:52-63]. Persons having ordinary skill in the art would appreciate 
such standard protocols are neither security protocols nor platform-level network security 
protocols. If the applicants had intended platform-level network security protocols to be 
equivalent to typical network protocols (e.g., TCP/IP), an assertion to which the 
applicants do not agree and which is not consistent to persons having ordinary skill in the 
art, then the applicants' discussion of a protocol stack (i.e., see item 256) in the instant 
specification would be meaningless. 

For at least the foregoing reasons, the applicants respectfully submit that 
independent claim 1 is allowable over the art of record, and the rejection of claim 1 and 
claims 2, and 4-8 dependent thereon must be withdrawn. 

Additionally, even if the PSR's described by Krishnaswamy et al. were properly 
construed as a platform-level network security protocol, an assertion to which the 
applicants do not agree, Krishnaswamy et al. still fail to describe or suggest such 
platform-level network security protocols associated with an extensible firmware 
interface (EFI). In particular, the examiner appears to contend (see page 2 of the official 
action) that the PSR's (see items 24A through 24N of Krishnaswamy et al.) and/or the 
Network Interrupt Service Routine (NISR - see item 22 of Krishnaswamy et al.) are 
somehow implemented in a manner similar to an extensible firmware interface. While 
the examiner merely asserts that the NISR of Krishnaswamy et al. is separate from an 
operating system, Krishnaswamy et al. clearly describe that the NISR is invoked by the 
operating system, thereby illustrating a dependency by the NISR on the operating system 
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when receiving packets. [Krishnaswamy et al., 5:25-28]. An even more intimate and 
dependent connection between the NISR and the operating system is evident because 
Krishnaswamy et al. describe that the NISR makes kernel function calls, which allow the 
operating system to invoke rate limiting processes. [Krishnaswamy et al, 5:44-52]. In 
other words, but for the actions of the operating system, the NISR described by 
Krishnaswamy et al. would not function and, thus, Krishnaswamy et al. fail to describe or 
suggest an extensible firmware interface, much less one or more platform-level network 
security protocols associated with an EFI. 

The applicants invite the examiner to study information pertinent to the EFI, as 
suggested by the instant application in paragraph [0013], to better understand the 
operating system independence facilitated by the EFI. In particular, the applicants submit 
herewith an Information Disclosure Statement that, inter alia, provides a general 
description of the EFI concept. More specifically, the submitted reference entitled, 
"Solving BIOS Boot Issues with EFI" clearly identifies EFI as an operating system 
independent interface, which is a concept that Krishnaswamy et al. lack. 

Accordingly, for at least the aforementioned reasons the applicants maintain that 
independent claim 1 is allowable over the art of record, and that the rejection of claim 1, 
and claims 2, and 4-8 dependent thereon, must be withdrawn. 

Independent claims 17, and 24 are also patentable over the art of record for at 
least the reasons set forth above in connection with claim 1 . Thus, the applicants 
respectfully submit that these claims and all claims dependent thereon are also in 
condition for allowance. Reconsideration is respectfully requested. 
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New independent claim 3 1 is also allowable. In particular, claim 3 1 recites, inter 

alia, identifying a security condition associated with a retrieved network packet with an 

operating system independent network security framework. None of the cited references 

describes or suggests identifying a security condition associated with a retrieved network 

packet with an operating system independent network security framework, as recited in 

claim 31. As described above in view of independent claim 1 , Krishnaswamy et al. 

describes handling packets in a manner dependent upon operating system commands or 

instructions. 

Thus, for at least the foregoing reasons, the applicants respectfully submit that all 
pending claims are now in condition for allowance. If there are any remaining issues in 
this application, the applicants urge the examiner to contact the undersigned attorney at 
the number listed below. 

The Commissioner is authorized to charge any deficiency in the enclosed check 
toward payment of any fee due for the filing of this paper to deposit account number 50- 
2455. 

Respectfully submitted, 

/Mark G. Hanlev/ 

Mark G. Hanlcy 

Reg. No. 44,736 

Attorney for Applicant(s) 

150 S. Wacker Drive, Suite 2100 

Chicago, IL 60606 

(312) 580-1020 

October 26, 2007 
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